home *** CD-ROM | disk | FTP | other *** search
/ Archive Magazine CD 1995 / Archive Magazine CD 1995.iso / discs / prog_disc / volume_1 / issue_10 / modeconv / article
Encoding:
Text File  |  1995-06-13  |  8.3 KB  |  156 lines
  1.      
  2.      More Mode Conversions
  3.      Robin Newman
  4.      
  5.      
  6.      Spurred on by last monthUs Archive, Robin has sent us two machine
  7.      code  utilities  and two BASIC programs which will convert mode 7
  8.      screens either to mode 4 (monochrome) or mode 9. The main purpose
  9.      of these is to allow a suitable graphics screen dump to  be  used
  10.      to  print  out  these  screens, but they can also just be used to
  11.      produce the converted screen. The  starting  point  was  a  BASIC
  12.      program called Simul8 first broadcast in 1984 on CEEFAX to enable
  13.      users  to  dump  CEEFAX  pages to a printer, by converting MODE 7
  14.      screens to MODE 4. First of all I converted  this  from  lots  of
  15.      IFUs  and  GOTOUs  to  using  CASE  and  multi-line  IF THEN ELSE
  16.      statements. Also, I developed one or  two  other  routines  which
  17.      allowed  the original MODE 7 screen to be saved and then restored
  18.      after the conversion/dump process was completed. At this stage  I
  19.      also  realised  that the same program could easily be modified to
  20.      convert MODE 7 to MODE 9.
  21.      
  22.      The next stage was to try and rewrite the  BASIC  progam  in  ARM
  23.      assembler.  This  was  done  partly  as  an exercise, but also to
  24.      produce a much more convenient utility which could be called from
  25.      any BASIC program where it was desired to dump a mode  7  screen.
  26.      The  format  decided  upon was to have a command *M7M4 (or *M7M9)
  27.      followed by a parameter which detailed the dump to be used:  e.g.
  28.      *M7M4  HardcopyFX,  or  *M7M4  Mydump.  The  utility  checks  the
  29.      screenmode when it is called and if it is already a graphics mode
  30.      merely passes the command onto the dump routine. If  however  the
  31.      screen  mode  is  7,  the utility first saves the existing mode 7
  32.      screen and current character set before redefining the  character
  33.      set  and converting the screen and calling the dump routine. When
  34.      the dump has completed, control is passed  back  to  the  utility
  35.      which  restores  the  original  screen  and  character set before
  36.      exiting. Thus  the  process  is  completely  transparent  to  the
  37.      calling  program.  In  addition, it is possible to save converted
  38.      screens merely by changing the command line to  *M7M4  SCREENSAVE
  39.      myscreen,  or  even  *M7M9 FASTSAVE myscreen if you have the FAST
  40.      screen load/save module installed. To facilitate testing, I  have
  41.      also  included  a  dummy  RdumpS  called  WAIT  (with source code
  42.      WAITsrc) which merely waits  for  a  key  to  be  pressed  before
  43.      returning.
  44.      
  45.      Machine Code Technicalities
  46.      
  47.      The  source  code  for  M7M4  on  the  program  disc  is  heavily
  48.      commented, so readers should be able to follow how the code  fits
  49.      in  with the original BASIC progam. However there are perhaps one
  50.      or two features which may be of interest to those trying to write
  51.      there own transient utilities. First, the object code is  set  to
  52.      type  &FFC  in  line 190, which indicates to the operating system
  53.      that it is a transient which should be loaded and run in the  RMA
  54.      area.  This gives one potential problem. There must be sufficient
  55.      free room in the RMA for the program to work.  If  you  have  not
  56.      loaded  any  other modules this is likely to be the case. However
  57.      if you QUIT to the supervisor mode and then  load  in  a  module,
  58.      when you restart BASIC it appears to claim back any remaining RMA
  59.      space.  The  cure  appears  to  be  to  type  *M7M4 WAIT from the
  60.      no-language environment before starting up BASIC. This claims the
  61.      required space which is released on exit, but  NOT  reclaimed  by
  62.      BASIC when it starts up unless you issue an RMTidy command first.
  63.      
  64.      The  other main problem with transients is that there is a bug in
  65.      the stack pointer which is passed to the transient on  entry.  It
  66.      is  not positioned correctly and calls to OS routines from within
  67.      the transient can result in corruption of the stack. The solution
  68.      is to subtract around 30 bytes from the stack pointer  passed  in
  69.      R13  before  you  start  using  it.  Other  details  on transient
  70.      operation are given on page 353 of the PRM. A workspace  of  1024
  71.      bytes  is  automatically  allocated on entry (pointed to by R12).
  72.      However, in this case rather more than that is required to  store
  73.      the original character set and the mode 7 screen. Thus, a call is
  74.      made  to XOS_Module to claim extra space in which to store these.
  75.      Notice the use of the X prefix here and in various other OS calls
  76.      within the utility. This ensures that if an error  occurs  within
  77.      the  call  that  control  is  retained  by the user. The error is
  78.      signified by the V bit being set in the processor  status  flags.
  79.      Appropriate  error  action  can  then be taken. In fact two error
  80.      messages are used in the utility. (lines 2300, 2310). These error
  81.      blocks consist of an error number, followed by the  error  string
  82.      and  terminated  with  a  0 byte. For lack of any allocated error
  83.      numbers, I have used 0 in each case. R0 is set to  point  to  the
  84.      error  number  and  the  control is passed to the calling program
  85.      with the V status flag being set on exit (lines 510-520). In this
  86.      way the user  can  deal  with  errors  using  standard  ON  ERROR
  87.      techniques.  Any  errors  occuring  within  the  DUMP routine are
  88.      similarly passed back to the calling program to deal  with  (e.g.
  89.      timeout  if  the  printer  is  offline).  Here  the  procedure is
  90.      slightly trickier, because we  first  have  to  ensure  that  the
  91.      original  mode  7  screen and character set are restored and that
  92.      the RMA workspace claimed is released. The solution  is  to  save
  93.      the  error  details on the stack, carry out the house keeping and
  94.      then retrieve the error information and exit.
  95.      
  96.      No doubt  there  are  other  points  which  may  require  further
  97.      clarification, but I hope that readers will be encouraged to have
  98.      a  go  at  writing  in ARM assembler. I find it a lot easier than
  99.      writing in 6502 assembler and you are really spoilt with  such  a
  100.      wealth  of  OS  calls  to  choose  from.  May  I also commend the
  101.      technique of trying out your  ideas  in  BASIC  first.  With  the
  102.      complex logic of this current example I am sure that I would have
  103.      floundered if I had gone straight into assembler.
  104.      
  105.      To use the programs:
  106.      
  107.      First  CHAIN"M7generate".  This program will draw a mode 7 screen
  108.      and save it as Rm7saveS. You  may  find  the  screensave  routine
  109.      useful for use in other programs.
  110.      
  111.      Secondly  type  in and CHAIN WAITsrc which will produce the dummy
  112.      printdump *WAIT.
  113.      
  114.      The BASIC programs can be tested by CHAINing either ARCSIMUL8  or
  115.      ARCSIMCOL  (which  is  produced by amending ARCSIMUL8 as shown in
  116.      the table below). When prompted for a filename enter m7save.  The
  117.      program  will pause at various stages until you press <space>. If
  118.      you wish to produce a real print dump, then amend the programs as
  119.      detailed in the REM statements.
  120.      
  121.      To use the machine code  transients,  CHAIN  "M7M4src"  from  the
  122.      program  disc  to  produce  M7M4.  You  can then CHAIN the progam
  123.      TESTBED to test this. Once again, enter the filename  m7save  and
  124.      the  program  will  pause  at each stage until you press <space>.
  125.      M7M9src can also be tested using the  TESTBED  program  with  the
  126.      dump line suitably altered.
  127.      
  128.      On the program disc, in the ModeConv directory, you will find:
  129.      
  130.      ARCSIMUL8 Mode 7 to Mode 4 converter
  131.      
  132.      ARCSIMCOL Mode  7 to Mode 9 converter (note that this is produced
  133.      by making simple changes to ARCSIMUL8)
  134.      
  135.      M7M4src Source code for *M7M4 Mode 7 to Mode 4 converter
  136.      
  137.      M7M4  Transient utility. Mode 7 to Mode 4 converter
  138.      
  139.      M7M9src Source code for *M7M9 Mode 7 to Mode  9  converter  (note
  140.      that this is produced by making simple changes to M7M4src)
  141.      
  142.      M7M9  Transient utility. Mode 7 to Mode 4 converter
  143.      
  144.      WAIT  Dummy dump utility: *WAIT waits for a key press
  145.      
  146.      WAITsrc  Source code for *WAIT
  147.      
  148.      TESTBED A program to test the operation of M7M4 and M7M9
  149.      
  150.      M7generate A  program  to  generate  and  save  a specimen mode 7
  151.      screen
  152.      
  153.      M7save  The saved Mode 7 screen
  154.      
  155.      
  156.